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Remarks/Arguments 

Claims 1-32 are now pending in this application. In the December 12, 2003 
Office Action, claims 1-14 and 17-32 were rejected under 35 U.S.C. § 102(e) as being 
anticipated by U.S. Patent No. 6,269,254 to Mathis (hereinafter "Mathis"). Claims 15 
and 16 were rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent 
Publication No. 2002/0052968 to Bonefas et al (hereinafter "Bonefas"). 

For the reasons set forth below, the applicants respectfully request reconsideration 
and immediate allowance of this application. Prior to discussing the reasons why the 
applicants believe that the claims currently pending in this application are allowable, a 
brief description of the present invention and the cited reference is presented. 

Summary of the Invention 

The present invention provides a Radio Interface Layer (RIL) between the radio 
on a cell phone and the software of the cell phone. The RIL is an Application Program 
Interface (API) set that provides a level of abstraction between the radio and software of 
a cell phone. According to one embodiment, the RIL comprises a proxy layer and a 
driver layer. The RIL proxy layer is located just below application modules for 
communication with the applications. The RIL driver layer is located between the RIL 
proxy layer and the radio hardware to communicate with the proxy layer and radio 
hardware. 

The RIL allows applications running on an operating system in the cellular 
telephone to issue commands without knowledge of the underlying radio structure of the 
cellular telephone and without specific knowledge of the cellular network being used. 
For example, modifying a device to operate on a GSM network instead of a CDMA 
network would only require replacing the RIL driver layer and the radio and the rest of 
the phone would work as it did in the GSM network. 

The proxy layer is hardware-independent while the driver layer is hardware- 
specific. For this reason, the RIL provides a platform for third party software developers. 
Software applications may be easily written to work with the RIL because the 
applications use well-known top-level APIs which are sent to the RIL. The RIL will then 
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perform appropriate processing of these top-level APIs and, if necessary, send the 
appropriate command to the radio to perform a specific action. Similarly, radio 
manufacturers no longer have to worry about receiving and keeping track of calls from 
multiple client applications because all of these functions are handled by the RIL. 
Without the RIL, each component (i.e., TAPI, SIM manager, SMS manager, etc.) of the 
phone would have to understand how to communicate to the radio directly. Because it 
would be difficult for hardware manufacturers to implement a TAPI driver, a SMS driver, 
a SIM driver, etc., the RIL was created to sit between the radio and the TAPI driver, the 
SMS driver, the SIM driver, etc. 

Summary of the Cited Reference 

Mathis describes supporting a dual-mode call on a GSM radio telephone using a 
Java telephony API (JTAPI) and reducing the memory requirement for programs that are 
JTAPI compatible by grouping event classes. Mathis teaches using a JTAPI to interface 
Java application programs to service providers or to existing telephony APIs. Where 
GSM functions cannot be easily accessed using the existing JTAPI syntax and method 
signature, Mathis defines new methods or methods with different signatures. Mathis 
relies on applications written using JTAPI to achieve the desired dual mode call 
functionality specifically for GSM radio telephones. As will be discussed below, Mathis 
teaches specific use of JTAPI and GSM technology and does not teach utilization of a 
proxy layer for communication with applications and a driver layer for communication 
with the radio hardware and the proxy layer. 

Drawings 

The applicants have amended FIG. 2 to correctly designate the RIL proxy layer 
with reference number 235. The RIL proxy layer was inadvertently designated with 
reference number 215 in the original FIG. 2 as filed. Additionally, the applicants have 
amended FIGS. 1, 2, and 4 to eliminate the shading and increase the margins and FIG. 3 
to increase the font size. 
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Claim Rejections - 35 U.S.C. §102 - Mathis 

The Examiner rejected claims 1-14 and 17-32 under 35 U.S.C. § 102(e) as being 
anticipated by Mathis. The applicants respectfully submit that Mathis fails to teach, 
suggest, or describe each element of the embodiments of the present invention recited in 
claims 1-14 and 17-32. 

Independent Claim 1 

Mathis does not teach, suggest, or describe each recitation of independent claim L 
The applicants have amended independent claim 1 to clarify the abstraction capabilities 
of the recited embodiment. Specifically, Mathis does not teach, suggest, or describe, "a 
set of application programming interfaces (APIs) for abstracting out multiple radio 
technologies without knowledge of the telephony radio or cellular network" or "wherein 
the abstraction layer comprises a proxy layer and a driver layer," 

Mathis was designed to address "a number of problems [that] lie in the way of 
using JTAPI as a telephony API for a Global System for Mobile (GSM) radio telephone." 
Mathis, column 2, lines 26-29. Therefore, Mathis teaches only using the GSM standard. 
Further support for Mathis' exclusive teaching of using a GSM telephone can be found, 
inter alia, in column 3, lines 57-59; column 4, lines 54-58; column 5, lines 16-18; column 
5, line 57 - column 6, line 2; and column 7, lines 2-3. Since Mathis teaches adaptation of 
JTAPI for use with a GSM radio telephone, Mathis does not teach, suggest, or describe 
"abstracting out multiple radio technologies without knowledge of the telephony radio or 
cellular network" as recited in claim 1 . 

/ Further, Mathis does not teach, suggest, or describe an abstraction layer that 
comprises "a proxy layer and a driver layer" as set forth in claim 1. Mathis teaches Java 
applications using JTAPI commands for communication with other layers. Mathis does 
not teach a proxy layer and a driver layer. The December 12, 2003 office action equated 
the "Java RUN-TIME machine" in FIG. 8 of Mathis with the proxy layer recited in claim 
7. The applicants disagree for the reasons stated below with respect to independent claim 
7. Therefore, because Mathis teaches use of a GSM radio telephone only and fails to 
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teach an abstraction layer that comprises a proxy layer and a driver layer, claim 1 is 
allowable over Mathis. 

Independent Claim 7 

Mathis does not teach, suggest, or describe each recitation of independent claim 7. 
In particular, Mathis does not teach, suggest, or describe a proxy layer and a driver layer, 
"wherein the proxy layer transforms the API to an input/output control (IOCTL) code and 
sends the IOCTL code to the driver layer; and wherein the driver layer communicates 
with the proxy layer and the radio, the driver layer receiving an IOCTL code and 
transforming the IOCTL code into a command understood by the radio to perform the 
particular function." As discussed above, Mathis does not teach an RIL comprising a 
proxy layer and a driver layer. 

In the December 12, 2003 office action, the "Java RUN-TIME machine" 
described by Mathis is equated with the proxy layer of the embodiment of claim 7. The 
applicants respectfully disagree. The applicants submit that the Java RUN-TIME 
machine of FIG. 8 simply enables the Java code of the application to run. The Java 
RUN-TIME machine does not transform a called API to an IOCTL code and send it to a 
driver layer. Further, the applicants submit that neither FIG. 7 nor TABLE 3 of Mathis 
depicts a driver layer that receives the IOCTL code from the proxy layer and transforms 
it into a command understood by the radio to perform the particular function, as 
suggested by the office action. FIG. 7 of Mathis illustrates a network configuration 
where a JTAPI application runs on a remote workstation and communications with a 
centralized server that manages telephony resources. FIG. 7 does not identify a driver 
layer that communicates with the proxy layer and the radio. In fact, FIG. 7 of Mathis 
shows that the layer immediately above the hardware layer in the Mathis configuration 
contains a plurality of modules, XTL, TSAPI, TAPI, other APIs, rather than a driver 
layer as taught by the present invention. Accordingly, for at least these reasons, 
independent claim 7 is allowable over Mathis. 



11 



Serial. No. 09/788,317 



Independent Claim 9 

Mathis does not teach, suggest, or describe each recitation of independent claim 9. 
In particular, Mathis does not teach, suggest, or describe a proxy layer and a driver layer, 
"causing the proxy layer to translate the RIL API into IOCTL codes; sending the IOCTL 
codes to the driver layer; translating the IOCTL codes to a command corresponding to the 
action, wherein the command will be understood by the radio; and sending the command 
to the radio." For at least the reasons discussed above with respect to claim 7, 
independent claim 9 is allowable over Mathis, 

Independent Claim 17 

Mathis does not teach, suggest, or describe each recitation of independent claim 
17. In particular, Mathis does not teach, suggest, or describe "sending the RIL API call 
to a proxy; at the proxy, converting the RIL API call to a command understood by a radio 
driver; transmitting the radio driver command from the proxy to the radio driver; [and] 
transmitting a radio command from the radio driver to the radio." As discussed above, 
Mathis does not teach a separate proxy layer and driver layer. Therefore, the steps 
involving the proxy and driver layers could not be taught by Mathis, Accordingly, claim 
1 7 is allowable over Mathis. 

Claim Rejections of Independent Claims 15 and 16 - 35 U.S.C. §102 - Bonefas 

The Examiner rejected claims 15 and 16 under 35 U.S.C. § 102(e) as being 
anticipated by Bonefas. The applicants have canceled claims 15 and 16. Consequently, 
the rejections are moot. 

Dependent Claims 18 and 20-22 

The applicants have amended claims 18 and 20-22 to reflect the amendments 
made to independent claim 17. Because Mathis does not teach, suggest, or describe 
every element of claims 18 and 20-22 and because claims 18 and 20-22 depend from 
allowable independent claim 17, dependent claims 18 and 20-22 are allowable over 
Mathis. 
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Dependent Claims 2-6, 8, 10-14, 19 and 23-32 

Because Mathis does not teach, suggest, or describe every element of claims 2-6, 
8, 10-14, 19 and 23-32 and because claims 2-6, 8, 10-14, 19 and 23-32 depend from 
allowable independent claims 1, 7, 9, and 17, dependent claims 2-6, 8, 10-14, 19 and 23- 
32 are allowable over Mathis. 



In view of the foregoing amendment and remarks, the applicants respectfully 
submit that the present application is in condition for allowance. Reconsideration and 
reexamination of the application and allowance of the claims at an early date is solicited. 
If the Examiner has any questions or comments concerning this matter, the Examiner is 
invited to contact the applicants' undersigned attorney at the number below. 



CONCLUSION 



Respectfully submitted, 



MERCHANT & GOULD 




March 12, 2004 



Leonard J. Hope 
Reg. No. 44,774 



Merchant & Gould 
P.O. Box 2903 

Minneapolis, Minnesota 55402-0903 
Telephone: 404.954.5100 
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